Summary

• Adds validation of requested csp type & acr during SiS /authorize against saved ClientConfig service_levels and credential_service_providers attributes.
• Clients default to accepting all credential_service_providers (idme, logingov, mhv, dslogon) & service_levels (ial1, ial2, loa1, loa3, min).
• Failed validation results in MalformedParamsError with "Type|ACR is not valid".
• Existing type & acr validation against saved SiS constants is now redundant and has been removed; ClientConfig service_levels and credential_service_providers attributes are already validated against the same constants.

Related issue(s)

• Prevent MHV and DSLogon options for rep flow va.gov-team#78699
• Database PR: [78699] adds service_levels and credential_service_providers attributes to ClientConfig #16238

Testing done

• New code is covered by unit tests
• To test, modify the service_levels or credential_service_providers values of your chosen ClientConfig to remove the CSP type or ACR you wish to test with

client_config = SignIn::ClientConfig.find_by(client_id: 'vaweb')
client_config.credential_service_providers = ['logingov']
client_config.service_levels = ['ial2']
client_config.save!

• Attempt a SiS login with the prohibited values

# Bad CSP
localhost:3000/v0/sign_in/authorize?type=idme&acr=loa1...

# Bad ACR
localhost:3000/v0/sign_in/authorize?type=logingov&acr=ial1...

• Your /authorize call should fail with the following errors

# Bad CSP
[SignInService] [V0::SignInController] authorize error -- { :errors => "Type is not valid", :client_id => "vaweb", :type => "idme", :acr => "loa1" }

# Bad ACR
[SignInService] [V0::SignInController] authorize error -- { :errors => "ACR is not valid", :client_id => "vaweb", :type => "logingov", :acr => "ial1" }

What areas of the site does it impact?

SiS authentication.

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected